Enhanced mobility and address resolution in a wireless premises based network

ABSTRACT

A premises based wireless network having a multi-segment wired network and a plurality of wireless access points connected to the wired network. The wired network operates according to a wired network protocol which may be the Internet Protocol. Wireless terminals communicate with the wireless access points according to a wireless network protocol, inconsistent with the wired network protocol. Each of the wireless terminals has a wired network address corresponding to one of the wireless access points. Each wireless terminal also has an address according to the wired network protocol. As the wireless terminals roam throughout the premises, protocol tunnels route communications between wireless terminals, thereby preserving communications while roaming by allowing the wireless terminals to retain their wired network addresses during the ongoing communications. The wireless terminals are connected to wireless access points. These wireless access points are in turn linked by data link tunnels to a root access point for a subnet. The data link tunnels enable the root access point for a subnet to forward data to the wireless access points. The forwarded data is not bridged onto the particular subnet that connects the wireless access point and the root access point for that subnet.

CROSS-REFERENCES To RELATED APPLICATIONS

The present case is a continuation of U.S. application Ser. No.09/183,767 filed Oct. 30, 1998, (which is to issue as U.S. Pat. No.6,701,361 on Mar. 2, 2004), which is a continuation-in-part of U.S.application Ser. No. 08/916,601 filed Aug. 22, 1997, which claims thebenefit of U.S. Provisional Application No. 60/024,648 filed Aug. 22,1996, and U.S. Provisional Application No. 60/043,395 filed Apr. 2,1997, all of which are hereby incorporated herein by reference in theirentirety.

BACKGROUND

1. Technical Field

The present invention relates generally to premises based wirelessnetworks wherein wireless terminals roam between network segments andutilize address resolution techniques for data packet routing purposes;and, more particularly, it relates to techniques for enhancing themobility of such wireless terminals within the wireless networks whileminimizing wireless traffic for address resolution.

2. Related Art

Communication systems often include interconnected wired and wirelessnetworks that together support communication within an enterprise. Thesecommunication systems typically include one or more wired networks thatconnect network elements such as workstations, servers and accesspoints. Communication cells established by wireless access points (APs)provide links between network elements connected to the wired backboneand mobile terminals. Such communications often pass through both thewireless and wired networks.

Wired networks typically operate according to one or more communicationprotocols, or protocol stacks that were specifically designed withstrategies to maintain and manage wired networks. Similarly, wirelessnetworks have evolved with protocols and associated maintenancestrategies to support mobile network nodes and other uniquecharacteristics associated with wireless network. Thus, it is oftendifficult to merge wired and wireless networks together withoutdegrading performance on either the wired or wireless network.

For example, in conventional installations, APs are used to bridgebetween the wired and wireless networks. However, higher level protocolsoperating in the wired networks often create problems for the wirelessnetworks, especially in those wireless networks where terminalsfrequently roam. Specifically, when terminals that communicate with afirst AP on one IP (internet protocol) segment of a wired LAN (localarea network) roam to communicate with a second AP attached to a secondIP segment of the wired LAN, ongoing communication may be lost due tothe a need to reregister the roaming device on the second IP segment andunregister that device from the first IP segment. Thus, IP nodes cannottransparently roam to another IP subnet. Further, because the APs indifferent IP segments often reside adjacent one another, the roamingterminals frequently move back and forth between the cells, creatingsignificant problems in the network.

SUMMARY OF THE INVENTION

In order to overcome the shortcomings described above and additionalshortcomings, a wireless network according to the present inventionincludes a multi-segment wired network and a plurality of wirelessaccess points connected to the wired network. The wired network operatesaccording to a wired network protocol which may be the InternetProtocol. Wireless terminals communicate with the wireless access pointsaccording to the wired network protocol, inconsistent with the wirelessnetwork protocol. Each of the wireless terminals has a wired networkaddress corresponding to one of the wireless access points. As thewireless terminals roam throughout the premises, protocol tunnels routecommunications between wireless terminals via the wired network, therebypreserving communications while roaming by allowing the wirelessterminals to retain their wired network addresses during the ongoingcommunications. Such protocol tunnels are transparent to the wirednetwork.

Additional functionality is provided through the use of data linktunnels that connect access points within a wireless network. The datalink tunnels allow passage of data under the wired network protocol towireless terminals operating under the wired network without extraneousoverhead in a communications protocol.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a drawing of an exemplary enterprise network built inaccordance with the present invention utilizing tunneling to accommodatemigration between IP network segments.

FIG. 2 is a drawing providing an exemplary illustration of access pointinteraction via an IP router to carry out IP tunneling in accordancewith the present invention.

FIG. 3 is a drawing of an exemplary protocol stack used in an accesspoint of the present invention such as one of those shown in FIGS. 1 and2 which has an IP port.

FIG. 4 is a drawing illustrating the operation of the present inventionwith a roaming IP terminal in an enterprise network built in accordancewith the present invention.

FIG. 5 is a drawing illustrating a variation from that of FIG. 4 used toillustrate further aspects in the enterprise network built in accordancewith the present invention relating to roaming.

FIG. 6 is a drawing of an exemplary enterprise network used toillustrate the functionality of address resolution using ARP proxyservers in accordance with the present invention.

FIG. 7 is a drawing of an exemplary enterprise network used toillustrate the functionality of address resolution using ARP translationservers in accordance with the present invention.

FIG. 8 a is a drawing illustrating operation of an augmenting agentbuilt in accordance with the present invention which supplementsoff-the-shelf protocol stacks to support various enhanced features thatmay prove desirable in specific enterprise network configurations.

FIG. 8 b is a drawing illustrating an alternate implementation of theaugmenting agent of FIG. 8 a wherein, instead of operation as anindependent, monitoring application, the augmenting agent operates as ashim between the proprietary or defacto industry standard drivers andthe higher level protocols.

FIG. 9 is a block diagram of a communication system illustrating the useof an IP tunnel and a data link tunnel to access a roaming terminal inaccordance with the invention.

FIG. 10 is a drawing illustrating a protocol stack associated with theaccess point at the endpoints of the IP tunnel and the data link tunnelin FIG. 9.

FIG. 11 is another drawing illustrating a protocol stack associated withthe access point at the endpoints of the IP tunnel and the data linktunnel in FIG. 9.

DETAILED DESCRIPTION

FIG. 1 is a drawing of an exemplary enterprise network 100 built inaccordance with the present invention utilizing tunneling to accommodatemigration between IP network segments. An enterprise as used hereinrefers to a business operation which may be self contained within asingle premises or within multiple premises. For example, the enterprisenetwork may be a wired and wireless network used within a singlewarehouse to support inventory control. It may also include support formobile, vehicle based communication with such warehouse via a wide areanetwork (“WAN”). Likewise, the enterprise might also include a secondwarehouse or manufacturing facility located near or remote to thewarehouse with wired, satellite or WAN connectivity.

In particular, within the enterprise network 100 of FIG. 1, theprotocols of the present invention, hereinafter referred to as OWL (openwireless local area network) protocols, support a variety of featureswhich enhance mobile or portable terminal mobility while minimizingtransmissions within the wireless networks. The OWL protocols functionat the MAC (media access control) sub layer of the ISO (industrystandards organization) protocol stack and allow the mobile networknodes (e.g., wireless terminals, printers, code readers, etc.) to roamfrom one wireless access point (OWL AP) to another in a manner which istransparent to higher layer protocols. The features of the presentinvention may be viewed as extensions to wireless network architecturessuch as those found in Appendix A entitled “OWL Network Architecture”,Appendix B entitled “Open Wireless LAN Theory of Operation,” Appendix Centitled “OWL Network Frame Formats,” and Appendix D entitled“UHF/Direct Sequence MAC-D Protocol Specification.”

The protocols of the present invention enable mobility across IP subnetsfor both IP and non-IP nodes, and enables non-IP nodes, on two or moreIP subnets, to communicate as if connected by a single (possiblybridged) local area network. These protocols do not require any changesto an existing TCP/IP protocol stack in IP routers or mobile IPstations.

Without the protocols of the present invention an AP (access point) 101and an AP 102 cannot belong to the same OWL network unless an IP router103 is configured to bridge OWL frames (i.e. DIX type hex. 875C). Assumethat an IP terminal 104 attached to the AP 101 is communicating with anIP host 105. The IP host 105 and the IP terminal 104 each have IPaddresses for a subnet 106. If the IP terminal 104 attaches to the AP102 (i.e. with a different LAN ID), then the IP host 105 cannot sendpackets to the IP terminal 104 because the IP router 103 would notforward packets within the subnet 106 to a subnet 107. A non-IP terminal108 on the subnet 106 cannot communicate with a non-IP host 109 onsubnet 107 unless the IP router 103 is configured to forward non-IPpackets. However, with the protocols of the present invention, such andother problems are overcome.

FIG. 2 is a drawing providing an exemplary illustration of access pointinteraction via an IP router to carry out IP tunneling. Features of theprotocols of the present invention may be implemented by adding alogical port to an OWL access point (AP) which is, essentially, a portto an “IP tunnel”. OWL packets and layer 2 data frames which are sent onthe logical “IP port” are encapsulated inside of IP packets and sentthrough the tunnel. An IP tunnel exists between the IP port on an APwhich “originates” the tunnel and an IP port on an AP which attaches tothe OWL spanning tree through the “remote” end of the tunnel. The IPtunnel functions as a branch in the OWL spanning tree.

The user configures the IP tunnel port (i.e. with the bridge port menu)on an OWL AP. By default, the IP port is enabled so that an AP canattach to an OWL network through the remote end of an IP tunnel; theuser can explicitly disable the IP port to prevent the AP from attachingthrough the tunnel. If the IP port is enabled, then the user canconfigure the port so that the AP will originate an IP tunnel. Typicallyonly a small number of APs should be configured to originate an IPtunnel. If an IP port is configured to originate a tunnel, then a listof 1 or more IP addresses must be defined for the port. A type isentered for each address in the list. The type can be UNICAST,BROADCAST, or MULTICAST. The AP software places no restrictions onaddresses in the list (other than the size of the list). The addresslist is selected so that IP packets destined to addresses in the listwill be heard by APs which should attach to the OWL network through anIP tunnel. For example, in FIG. 1, an IP tunnel can be establishedbetween the AP 101 and the AP 102 by enabling the AP 101 to originate anIP tunnel and adding the IP address of the AP 102 to the address listassociated with the IP port in the AP 101. The AP 101 and AP 102 areconfigured with the same OWL LAN ID.

An IP port can be configured so that it can only originate a tunnel ifit assumes the root node status or if it becomes the designated AP for asecondary LAN.

A set of permanent filters and a set of user-defined filters are used torestrict flooding through an IP tunnel. The filters can be used, forexample, to limit traffic through an IP tunnel to OWL frames and NorandNetwork Layer (NNL) frames. The permanent filters are used to prevent IProuting information packets and broadcast/multicast IP packets frompassing through an IP tunnel. By default, only NNL packets, OWL packets,ARP packets, and unicast IP packets with a protocol type of UDP, TCP, orICMP can pass through an IP tunnel. Some ICMP types and UDP/TCP protocolports are also filtered, by default, to prevent IP routing informationfrom passing through the tunnel. A “subnet filter” can be enabled if allmobile IP nodes belong to the same “root” subnet. Filters are discussedin more detail below.

The user can enable/disable a “proxy ARP server” or an “ARP translationserver” (discussed below) and, optionally, create permanent ARP serverentries. The user can also set a network wide parameter which preventsbroadcast ARP requests from being forwarded to radio terminals andthrough IP tunnels. The parameter can be set so that no ARP requests areforwarded or only those which cannot be “resolved” by the particular ARPserver.

Although the higher level protocols (e.g., such as that set forth inIEEE 802 standards) may prohibit a bridge from reordering (i.e.forwarded) frames, it is possible that frames forwarded through an IPtunnel may be reordered by the underlying network. The user canconfigure an IP port so that strict frame sequencing is enforced. Ifstrict frame sequencing is enabled, then the IP port will insert asequence number in outbound frames and cache address/sequence numberpairs for inbound frames. Delayed frames which arrive out-of-order aresimply discarded.

An IP port can be enabled on an AP configured with an IP address. If IPsubnet addressing is used, then the AP should also be configured with anIP subnet mask.

An OWL IP tunnel is logically equivalent to any other physical link(i.e. radio link) in the OWL spanning tree. An OWL AP forwards a packetalong a branch in the spanning tree by sending the packet to the MAC-Ddestination address of the next hop. The MAC-D addresses used on an IPport are IP addresses which identify the AP at each end of the tunnel.Note that the TCP/IP software in an AP is responsible for binding the IPaddress to the correct 802 LAN address (i.e. with ARP).

The root node and other attached OWL APs broadcast HELLO packets or“beacons” on each IP port and radio port once per HELLO period. The rootnode and designated APs also broadcast HELLO packets on ethernet links.If the port is an IP port, then a copy of the HELLO packet is createdfor each IP address in the user-defined list for the port. The MAC-Ddestination address, of the HELLO packet, is an IP address from thelist, and the MAC-D source address is the IP address of the AP. If thedestination IP MAC-D address in a HELLO packet is a multicast address,then the HELLO packet may be received by more than one AP. For example,an IP port on the root AP can be configured with the “all-subnets”address. In this case, no other configuration may be required, since allAPs in an enterprise IP network, potentially, can receive HELLO packetsaddressed to the all-subnets address. (Note that IP routers must beenabled to forward packets addressed to the all-subnets address or agroup address, if such an address is used.) As a second example, an IPport on the root AP can be configured with a list of unicast addresses,to limit HELLO propagation and/or to explicitly control which APs attachto the remote end of a tunnel.

The IP software in the AP binds the destination IP address in a HELLOpacket to an ethernet address. If the IP address type is UNICAST, thenthe first hop on the path to the IP destination is derived from the IProute table in the AP. Note that the user can configure a default routeand can also configure special routes for a specific IP address or groupof addresses. If the type is BROADCAST, then the destination ethernetaddress is the ethernet broadcast address, hexadecimal FFFFFFFFFFFF. Ifthe type is MULTICAST, then the HELLO packet is sent to a multicastethernet destination address which is formed from the IP addressaccording to RFC 1112. The first 3 bytes of the ethernet address arehex. E and the last 23 bits are taken from the last 23 bits of the IPaddress.

OWL APs which are on an IP subnet which is different than the IP subnetof the OWL root node, can attach to the OWL spanning tree through an OWLIP port. The “cost” associated with an IP port is greater than the costof an ethernet port, but less than the cost of a radio port. Anunattached AP may receive HELLO packets on one or more ports. If thelowest cost path to the root node is through an IP port, then an AP willsend an ATTACH request to the root node through the IP port. The MAC-Ddestination address of the ATTACH request is equal to IP address of thetunnel originator and the MAC-D source address is the IP address of theattaching AP. Note that the IP destination address is obtained from theMAC-D source address of a HELLO packet. The tunnel link is complete assoon as the attaching AP receives an ATTACH response on the IP tunnelport.

An AP which attaches through an IP tunnel link (or OWL radio link) canbe the designated AP for a secondary OWL ethernet LAN. An AP can be thedesignated AP for a secondary LAN at a given time. More than one AP,attached to the same secondary LAN segment, may receive HELLO packetsthrough an IP port (or radio port) if a multicast IP address is used orif two or more unicast addresses are defined (i.e. for redundancy). Theprotocol to elect the designated AP operates consistently whether thepath to the parent AP is through an IP tunnel or radio link. Thedesignated AP, for a secondary LAN, is always the parent of any other APwhich can bridge frames to the secondary LAN segment.

More particularly, in FIG. 2, a subnet 201 is the OWL primary LAN.Further a subnet 202 is an OWL secondary LAN, and an AP 212 is thedesignated bridge for the secondary LAN 202. OWL spanning tree branches221, 222 and 223 are denoted by dashed lines. The branch 222 from AP 212to a root AP 215 is through an IP tunnel via an IP router 205, which wasoriginated by the root AP 215. By default, an AP 213 can bridge framesonto subnet 202. Therefore, the AP 213 must attach to the OWL networkthrough the designated AP for the subnet 202, i.e., the AP 212. An AP214 is attached to the root AP 215 through an ethernet branch 221,rather than an IP tunnel branch, because the cost of an ethernet hop islower. Similarly, ethernet branch 223 exists between the AP 212 and theAP 213.

A node in an OWL network is identified by its MAC-R address which is a6-byte 802 (i.e. ethernet) address. A port on an OWL device isidentified by a MAC-D address. The path to an OWL node is defined by theOWL spanning tree, which can be derived from routing tables stored inAPs. The key to a routing table entry is a MAC-R 802 address. An APforwards an outbound ethernet frame, for example, by looking up thedestination ethernet address in a routing table. A MAC-D port addressand local port ID, stored in the route table entry for the destination,define the first hop on the path to the destination. If the first hop isthrough an IP tunnel, then the MAC-D address is an IP address whichidentifies an IP port at the remote end of the tunnel. The IP MAC-Dlayer encapsulates the frame inside of an IP packet and forwards it tothe remote IP port. The IP MAC-D layer in AP at the remote end of thetunnel removes the IP encapsulation and posts the frame to the MAC-Rlayer, which forwards the frame to its final destination.

The size of an encapsulated frame may exceed the maximum frame size foran ethernet link. The IP software in the AP is responsible forfragmenting and re-assembling packets which exceed the maximum ethernetframe size.

The MAC-D entity associated with an IP port on an AP passes a frame tothe local IP stack for transmission. The IP stack formats the IPpackets, binds the destination IP address to an ethernet address, andpasses the frame to its data link layer interface for transmission. Inan OWL AP, the data link layer interface for the IP stack exists on topof the OWL bridging layer. Therefore, the IP-encapsulated frame passesthrough the bridging layer and, possibly, through the MAC-R layer and asecond MAC-D layer before it is transmitted on a physical port. Thedestination ethernet address of the IP-encapsulated frame should be theethernet address of an IP router port attached to the local subnet. Ifthe destination ethernet address is unknown, then the frame wouldnormally be flooded. However, encapsulated frames, identified by the IPprotocol type, are always passed to the ethernet MAC for transmission.Received encapsulated frames are discarded by the bridging layer, if theinput source is not the ethernet MAC. This restriction prevents internalrouting loops in the AP and prevents tunnels from existing on top ofradio links. Note that the path cost would be distorted if an IP tunnelexisted over a radio link.

FIG. 3 is a drawing of an exemplary protocol stack used in a accesspoint of the present invention such as those shown in FIGS. 1 and 2which has an IP port. A dashed line 301 between an IP MAC-D entity 303and a GRE transport entity 305 logically represents a path through theprotocol stack for IP-encapsulated frames. More particularly, this pathflows between the GRE transport entity 305 the IP MAC-D entity 303 viaan IP layer 307, a data link layer 309, a bridge layer 311 and a MAC-Rentity 313. Descriptions regarding other pathways through the protocolstack may be found, for example, in Appendix B.

If the AP receives a frame and the destination is unknown, the frame maybe flooded, depending on the configured flooding levels. Note that thedestination of a multicast frame is never known. Frame flooding throughan IP tunnel is consistent with flooding on any other link type. Ifmulticast hierarchical flooding is enabled, for example, then multicastframes which originate in the radio network are forwarded inbound to theprimary LAN. Multicast frames which originate on the primary LAN areflooded throughout the OWL network. The path to the primary LAN mayinclude an IP tunnel.

Flooding through an IP tunnel can be reduced with a number ofconfiguration options. As noted above, filters can be defined to preventsome types of frames from being forwarded.

Ethernet bridging can be disabled on selected OWL APs to preventflooding across subnet boundaries. In FIG. 2, for example, if bridgingis disabled on AP 2 and AP 3, then frames transmitted on subnet 2 willnot be bridged into the OWL network, and, therefore, will not be floodedto subnet 1. Only frames received on radio ports will be forwardedinbound by AP 2 and AP 3.

If unicast hierarchical flooding (see OWL theory of operation) isenabled, then unicast frames transmitted on subnet 1, the primary LAN,will not be flooded to subnet 2, if the destination is unknown; however,unicast frames will be forwarded from subnet 1 to subnet 2 if the rootAP has a route table entry for the destination and the first hop isthrough the IP tunnel link.

An AP will not forward a frame through an IP tunnel if the destinationethernet address identifies the default IP router port. An AP candetermine the ethernet address of its default IP router port from itslocal ARP cache.

As used herein, a “mobile IP node” is any IP node that can roam acrossIP subnet boundaries. In an OWL network, each mobile IP node isconfigured with a single IP address, which defines its “home” IP subnet.In theory, any IP subnet(s) can be a home subnet for mobile nodes. Inpractice, the IP subnet which is attached to the OWL root node is thepreferred home subnet for mobile IP nodes. In this case, the home subnetis equivalent to the OWL primary LAN. If the primary LAN is the same asthe home subnet and mobile nodes communicate exclusively with stationson the primary LAN, then MAC-level flooding and triangular routing canbe reduced or eliminated.

In an IP/ethernet network which uses subnet routing, a first IP nodesends an IP packet to a second node on the same subnet by sending the IPpacket to the ethernet address of the second node. If the second node ison another subnet, the first node sends the packet to the ethernetaddress of an IP router. The ethernet address is typically discoveredwith the ARP protocol. Since the destination MAC address of the IPpacket is an ethernet address, the packet will be forwarded correctly inan OWL network.

If a mobile IP node (or mobile non-IP node) roams away from its homesubnet and attaches to an AP on a “foreign” subnet, it must send anATTACH request to the OWL root node before it can send or receive dataframes. The ATTACH request fully establishes the path to the mobilenode. For example, the AP at the home end of the IP tunnel, which linksthe home and foreign subnets, will create a route entry for the mobilenode, which points to the tunnel as the first hop on the path to mobilenode, when it receives the ATTACH request from the terminal. The key tothe route entry is the ethernet address of the mobile node. If the APreceives an ethernet packet, with the destination ethernet address ofthe mobile node, then it will forward the encapsulated ethernet framethrough the IP tunnel.

If a mobile IP node is attached to an AP on a foreign subnet, then itstill responds to ARP requests which are transmitted on its home subnet.If multicast flooding is enabled, then broadcast ARP requests areflooded throughout the OWL network, including through OWL tunnel links.Therefore, the mobile node can receive the broadcast ARP request on theforeign subnet, and respond with a unicast ARP response, containing itsethernet address. Likewise, an ARP request from the mobile node will beflooded to the home subnet. Note that the target IP address, in an ARPrequest from the terminal, may designate either a target host or arouter port on the node's home subnet. In either case, IP packets areforwarded through the OWL network to the node identified by thedestination ethernet address.

FIG. 4 is a drawing illustrating the operation of the present inventionwith a roaming IP terminal in an enterprise network built in accordancewith the present invention. As shown, a mobile IP terminal 415 hasroamed from its home subnet, subnet 411, to an AP 403 on a subnet 412.The mobile IP terminal 401 may be any device which contains a radiotransceiver such as a portable computing device, a code reader, aprinter, digital camera, RF TAG, etc. An AP 401 serves as the OWL rootnode. An AP 402 is the designated AP for the secondary LAN which is thesubnet 412. The AP 402 is attached to the AP 401 through an IP tunnel421. The AP 403 is attached to the AP 402 through an ethernet link 425.Note that the physical path for the IP tunnel 421 between the AP 401 andthe AP 402 is through an IP router 423. The IP router 423 has two ports,port 431 attaches to the subnet 411 while port 432 attaches to thesubnet 412. The IP address for port 431 identifies subnet 411, while theIP address for port 432 identifies the subnet 412. The subnet 411 is theprimary OWL LAN.

As a first example, assume that the terminal 415 has been activelycommunicating with an IP host 441 when it roams from the AP 401 to theAP 403. When the terminal 415 roams, it must send an ATTACH request tothe root, and wait for a matching ATTACH response, before it can send orreceive data frames. The ATTACH request causes the root to update itsroute table entry for the terminal so that the first hop port and MAC-Daddress are its IP port and the IP address of the AP 402, respectively.The AP 402 and the AP 403 also update their routing tables to reflectthe new path. If the host 441 sends a packet to the terminal 415, thedestination ethernet address is the ethernet address of the terminal415. The packet will be routed to the terminal 415 via the tunnel 421.If the terminal 415 sends a packet to the host 441, the destinationethernet address will be the address of the host 441. The packet will beforwarded inbound until it reaches the primary LAN (the subnet 411),where it will be bridged and received by the host 441.

If the terminal 415 roams before it begins communicating with the host441, it does not know the ethernet address of the host 441. Thus, theterminal 415 sends a broadcast ARP request which contains the IP addressof the host 441 to determine the ethernet address of the host 441. TheAP 403 bridges the ARP request onto the subnet 412. No IP node on thesubnet 412 will respond to the ARP request because the target IP addressdoes match any of the subnet 412 IP addresses. The AP 402 receives andforwards the ARP request inbound through the IP tunnel 421 to the AP401. The AP 401 bridges the request onto the subnet 411, where it isreceived by the host 441. The ARP response is sent to the unicastaddress of the terminal 415. If the host 441 sends an ARP 441 requestwhich contains the IP address of the terminal 415, then the ARP requestcan either be serviced by a proxy ARP server (i.e. in the AP 401) orflooded outbound through the IP tunnel 421 and to the terminal 415.

FIG. 5 is a drawing illustrating a variation from that of FIG. 4 used toillustrate further aspects in the enterprise network built in accordancewith the present invention relating to roaming. The home subnet of an IPterminal 515 is a subnet 511. An IP router 523 has a port 531 which isthe default router port associated with the subnet 511 and a port 532associated with the subnet 512. The port 531 is the default router portfor the terminal 515; and the port 532 is the default router port for anIP host 541.

Assume the terminal 515 was actively communicating with the host 541when it roamed from an AP 501 to an AP 503. The host 541 is sending IPpackets to the terminal 515 which have a destination ethernet addressfor the port 532 on the IP router 523. The terminal 515 is sending IPpackets to the host 541 which contain the ethernet address of port 531on the router 523. After the terminal 515 roams, it will continue tosend packets with the ethernet address of the port 531. A packet fromthe terminal 515 will be bridged onto the subnet 512 by the AP 503. AnAP 502 will receive and forward the packet inbound to the primary LAN.The AP 501 bridges the packet onto subnet 511, where it will be receivedby the router 523 on the port 531. The router 523 will forward the IPpacket to the host 541 on subnet 512. A packet transmitted by the host541 will be forwarded from the subnet 512 to the subnet 511 by therouter 523. The AP 502 will not forward the packet, transmitted by thehost 541, inbound to the AP 501 if it has learned that the port 532 onthe router 523 is on the subnet 512. Otherwise, it will flood the (i.e.duplicate packet) packet to the subnet 511. Note that no ethernetadapter on the subnet 511 should receive the duplicate packet.

As before, ARP requests will be generated if the terminal 515 roamsbefore communicating with the host 541 (or if ARP caches are aged). Theterminal 515 will send an ARP request with the IP address of the port531 as the target IP address. The ARP request will be forwarded inboundthrough the IP tunnel 521 and bridged onto subnet 511 by the AP 501,where it will be received by the router 523. The router 523 will send aunicast ARP response packet to the terminal 515 which contains theethernet address of the port 531. The host 541 will send an ARP requestwith the IP address of the port 532 as the target IP address. The router523 will send a unicast ARP response packet to the host 541 whichcontains the ethernet address of the port 532. Note that the router 523will receive both ARP requests on both ports; however, it will(correctly) respond only to those ARP requests which match the port IPaddress. Also note that the AP 502 will learn that the ethernet addressof the port 532 is on the local subnet when it sends an ARP response.

The OWL/IP protocols run on top of an IP “transport-layer” protocoldefined in RFC 1701 entitled “Generic Routing Encapsulation (GRE)protocol.” The IP protocol type for GRE is decimal 47. GRE is used toencapsulate a variety of non-IP network layer protocols (i.e. to routenon-IP packets through an IP network). The GRE header is contained in 4or more bytes. Two of the bytes contained in the GRE header contain theDIX type of the encapsulated protocol, which is hexadecimal 875C forOWL/IP. The general format of an OWL/IP frame transmitted as a DIXethernet frame is shown below: Field Size Ethernet Destination Address 6bytes Ethernet Source Address 6 bytes Ethernet Version 2 Type (hex. 2bytes 800) IP Header (protocol = 47) 20 bytes GRE Flags 2 bytes GRE Type(hex. 875 c) 2 bytes MAC-D Protocol ID 1 byte MAC-D Control 1 byte MAC-DOWL LAN ID 1 byte MAC-D Fragment ID 1 byte MAC-D Length 2 bytes MAC-RControl 2 bytes MAC-R 802 Destination 6 bytes Address MAC-R 802 SourceAddress 6 bytes MAC-R Parameters M bytes 802.3 Length or DIX Type 2bytes LLC Header/Data N bytes

The first two bytes in the GRE header contain a flag which indicates ifthe GRE header contains an optional 4-byte sequence number. The sequencenumber can, optionally, be included if strict frame sequencing, throughan IP tunnel, must be enforced.

Filters may be used to prevent unwanted frame forwarding through anOWL/IP tunnel. For example, such filters may operate to preventforwarding of: (1) 802.1d bridge PDUs any OWL AP port; (2) IP packetswith a broadcast or multicast ethernet address (preventing nodes on aremote IP subnet from receiving “bridged” IP packets, for example); (3)IP packets with protocol types such as EGP, IGP, IDPR, IDRP, MHRP, DGP,IGRP, and OSPFIGP; (4) IP ICMP packets except types such as EchoRequest, Echo Reply, Destination Unreachable, Source Quench, Redirect,Alternate Host Address, Time Exceeded, Parameter Problem, Time Stamp,Time Stamp Reply, Address Mask Request, Address Mask Reply, and TraceRoute; (ICMP types which include Router Advertisement, Router Selection,Mobile EP types, and IPv6 types may not be forwarded); and (5) IP/UDP orIP/TCP packets with source or destination protocol port numbers such asRIP, RAP, and BGP.

Similarly, a user can explicitly filter DIX types, however, as adefault, only the following DIX types are forwarded: OWL (hex. 875C),NNL (hex. 875B), ARP (hex. 0806), and IP (hex. 0800). Further, IPprotocols can also be filtered. But, as a default, the IP protocolsICMP(1), UDP(17), and TCP(6) are not filtered. All such filters may bemodified or extended as proves desirable for a given enterprise networkinstallation.

The user can also enable subnet filtering for IP networks which usesubnet routing. Subnet filtering can be used if: a) all mobile nodesbelong to the same subnet as the root AP —the “root subnet;” and b) theroot AP initiates all IP tunnels. Servers/hosts can be on any subnet. Ifsubnet filtering is enabled, an AP forwards IP packets inbound throughan IP tunnel if the source IP address belongs to the remote subnet andthe source ethernet address identifies a mobile node in the sub treerooted at the AP. An AP forwards broadcast ARP packets (with an IPprotocol type) inbound through an IP tunnel if the source IP address, inthe ARP packet, belongs to the remote subnet and the source ethernetaddress identifies a mobile node in the sub tree rooted at the AP. Thisoption can be used in conjunction with hierarchical unicast flooding toeliminate unnecessary IP packet forwarding and inbound ARP flooding. Ifthe unicast hierarchical flooding option is used, then IP packets arenot forwarded from the root subnet unless the destination is in thesubtree below the root subnet. Note that multicast and broadcast IPpackets are not forwarded. In addition, a proxy ARP server or an ARPtranslation server can be used to prevent ARP flooding.

An OWL AP functions as a transparent MAC layer bridge. A transparentbridge may flood a frame, received on one port, to all other ports, ifthe destination is unknown. In an OWL network, unicast frames may beflooded through an IP tunnel if flooding is enabled. As noted above,broadcast and multicast IP packets are not forwarded through an IPtunnel. In many cases, flooding through an IP port can be eliminatedwith the “subnet filter” option and the hierarchical unicast floodingoption.

Occasionally, flooding through an IP tunnel may cause a duplicate IPpacket to be delivered to another “remote” subnet. This can happen, forexample, if an AP with an active IP port has not yet “learned” theethernet address of a router port which is on the same “local” subnet asthe AP. In this case, an IP packet addressed to the ethernet address ofthe router port may be flooded through the IP tunnel, by the AP, andalso forwarded by the IP router. However, the packet flooded through thetunnel should not be received by any ethernet adapter attached to theremote subnet because the destination ethernet address designates therouter port attached to the local subnet. It should be noted that IPdoes not provide “reliable” network layer services. Packets may be lost,duplicated, delayed, or delivered out-of-order.

An AP with an IP port may also occasionally flood IP packets to thewrong subnet(s), if the AP has not learned the destination address of alocal host. Again, such packets should not be received by any ethernetadapter on the remote subnet(s).

In general, an AP should not forward a frame through an IP tunnel, ifthe destination ethernet address of the frame identifies a node on thelocal subnet. An AP uses “backward learning” to discover which ethernetaddresses belong to nodes on the local segment. Learned addresses arestored in a “filtering database.” Filtering database entries are agedand discarded if the node associated with an entry is not active forsome period of time. An AP will not forward an ethernet frame, if it haslearned that the destination is on the segment on which the frame wasreceived. In an IP environment, packets destined for another subnet arealways addressed to the ethernet address of a router port on the localsubnet. Therefore, such packets are usually not forwarded (i.e. throughan IP tunnel) by an AP.

In practice, IP nodes do not transmit IP packets, without firsttransmitting an ARP request and receiving an ARP response. ARP cachesare typically aged, so ARP requests and responses are generatedperiodically for active nodes. Also, routers usually broadcast routinginformation packets periodically. In general, any periodic message willcause any AP on the local subnet to refresh its filtering database.Therefore, each AP on a subnet should have a fresh filtering databaseentry for each router port or host port attached to the subnet.

The following rules apply to typical OWL/IP protocol installations: (1)OWL/IP does not bridge across an IP router if the router is configuredto bridge OWL frames (i.e. DIX type hex. 875C); (2) OWL/IP does notbridge frames across an IP router, for some network protocol type, ifthe router is also configured to bridge the network protocol type. Forexample, NNL frames should not be bridged through an IP tunnel, if anyintermediate IP routers are configured to bridge NNL frames. Note thatsome routers (i.e. brouters) can be configured to bridge any frame typewhich cannot be routed; (3) OWL/IP should not be used to bridge frameswith routable non-IP network layer types (e.g. OWL/IP should not be usedto bridge Novell IPX frames in an environment which includes combinedIP/IPX routers.); (4) As a rule, OWL/IP can be used to bridge frameswith non-routable network layer types, where a “non-routable” type isany type which will not be forwarded by a router (e.g. NNL, for example,is a non-routable type); and (5) An OWL network should not be installedso that two IP subnets are bridged by a radio link. For example, in FIG.1, the spanning tree link between the AP 101 and the AP 102 should notbe a radio link. Note that the AP 102 will attach to the AP 101 throughits OWL/IP port, even if it has a physical radio link to the AP 101,because the cost of an IP tunnel hop is lower. In general, a path thatcan be bridged by single radio hop cannot include more than two IPtunnel hops and should include at least one IP tunnel hop. If IP roamingor NNL communications to a remote NNL host are not required, then eachset of OWL nodes contained within an IP subnet should be configured asan independent OWL network with a unique LAN ID.

In a typical IP/ethernet environment, the ARP protocol is used to bindan ethernet address to an IP address. An ARP request packet, whichcontains a target IP address, is sent to the ethernet broadcast address.Each IP node on the LAN receives and examines the request. The nodedesignated by the target IP address will return the ARP response packet,which contains its unicast ethernet address. If the target IP node ismobile, then the request must be flooded over a radio link(s) and,possibly, through an IP tunnel to reach the mobile node.

However, in many enterprise network installations, it may proveundesirable to flood ARP requests over radio links and tunnel links forseveral reasons. The most obvious reason is that it adds broadcasttraffic, which has added overhead on radio links. In addition, in atypical mobile node, the radio module interrupts its host processor whena frame is received with the unicast destination address of the mobilenode or a broadcast destination address. If the mobile node containspower-management logic, then the host processor may be “sleeping” when areceived frame arrives. If the radio module is enabled to receivebroadcast ARP requests, for example, then the host processor willconstantly be interrupted and awakened. On a busy IP LAN, the mobilenode would almost never sleep. Among other reasons, flooding through atunnel link also circumvents the ability of routers to contain trafficwithin LAN segments.

In some cases, a proxy ARP server can be used to reduce or eliminate theneed to flood ARP requests to mobile nodes through an IP tunnel or radioport. (Note that filters can be used to reduce non-ARP broadcasttraffic.) The proxy ARP server exists on each AP which can bridge to anethernet port. If the server is enabled, it maintains an ARP database,where each entry in the database contains a status, an age, and an IPaddress/ethernet address pair. Each address pair designates an ‘P nodewhich is on the server’s IP subnet. The status value can be “PROXY”,“LOCAL”, or “PENDING”. If the status is PROXY, then the server isservicing ARP requests for the associated IP node, which is in the OWLsub tree rooted at the AP. If the status is LOCAL, then the server haslearned that the target IP node is on the local ethernet link. A PENDINGentry is created when an ARP request is received and the server does nothave an entry for the target node. The age in an entry is set to 0 whenthe entry is created or updated, and is incremented once a minute.Entries in the database are indexed by the IP address and by theethernet address.

The AP bridging module calls the ARP server each time an ARP request isreceived, and passes a pointer to the ARP packet. The ARP server returnsa value to the bridging module which indicates if the request should beforwarded or discarded. There are two general cases —the request framecan either be received on an “inbound” link or an “outbound” link. Alink is inbound if the AP is attached to the link through its root port;otherwise, it is outbound. In the special case of the root AP, theprimary LAN is considered an inbound link. If an ARP request is receivedon an inbound link and the server has a PENDING entry, for the target IPaddress, then it indicates that the request should be flooded (i.e.outbound); otherwise, it indicates that it should be discarded. If theserver does not have an entry, a PENDING entry is created. Note that ifthe server receives another ARP request with the same target IP address,it will indicate that the request should be forwarded. If an ARP requestis received on an outbound link and the server does not have an entry orhas a LOCAL, then it indicates that the request should be forwardedinbound only, and a PENDING entry is created. If the server has aPENDING entry, then it indicates that the request should be flooded(i.e. forwarded inbound and, possibly, to other outbound ports). Ineither case, if the server has a PROXY entry for the target IP address,then the server will transmit a “proxy” ARP response, which contains theethernet address of the associated IP node, and indicate that the frameshould be discarded.

In an exemplary embodiment, the server follows the rules listed below tomaintain its ARP database and forward ARP request packets. Note that thedatabase can contain only one entry per IP address; therefore, before anentry is “created” any existing entry must be deleted. In thisdiscussion, a “route” can be a route table entry or a “secondary” entryin the AP bridge table. If the server indicates that an ARP requestshould be forwarded, then it is flooded according to ARP and multicastflooding configuration parameters.

(1) The ARP database is tightly coupled with routing tables in the AP.The ARP database cannot contain a PROXY entry for a node, unless thenode is in the spanning tree rooted at the AP. Therefore, a PROXY entrycannot be created unless the AP has a route to the node. A PROXY entryis deleted if the route to a node is deleted.

(2) The server in the root AP or in the designated AP for a secondaryethernet LAN, cannot create a PROXY entry for a node if the route to thenode is “distributed”. (A route is “distributed” if the first hop to thenode is through an AP on the same ethernet link, which is responsiblefor bridging frames to/from the ethernet link from/to the node.)

-   -   (3) The ARP database is never updated with an IP address which        belongs to another subnet. The ARP server always indicates that        an ARP request should be discarded if either the target or        source IP address belongs to a subnet which is not the same as        the subnet of the AP.

(4) If the server receives an ARP response packet on a non-ethernetport, it creates a PROXY entry for the target IP node (i.e. the nodewhich generated the response), if the AP has a consistentnon-distributed route to the node. If the route is distributed, a LOCALentry is created.

(5) If the server receives an ARP request packet on a non-ethernet port,it creates a PROXY entry for the source IP node (i.e. the node whichgenerated the request), if the AP has a consistent non-distributed routeto the node. If the route is distributed, a LOCAL entry is created.

(6) An IP node in the OWL network can explicitly register its IP addresswith the ARP server each time it sends an OWL ATTACH request packet. AnAP creates a PROXY entry for the source node if it is responsible forbridging frames to/from the source node on its ethernet port; otherwise,if the route is distributed, it creates a LOCAL entry. The ethernetaddress stored in the PROXY entry is the MAC-R source address of theATTACH request packet. The ARP database is not updated if the ATTACHrequest is invalid (i.e. out-of-sequence).

(7) If the server receives an ARP response packet on an ethernet port,it creates a LOCAL entry for the target IP node if it does not have anentry or if it has a LOCAL or PENDING entry. If it has a PROXY entry andthe AP is not the root AP, then an ALERT request is sent to the root AP.If the path to the node has changed, the root AP will return an ALERTresponse to delete the old path fragment.

(8) If the server receives an ARP request packet on an ethernet port, itcreates a LOCAL entry for the source IP node, if it does not have anentry or if it has a LOCAL or PENDING entry. If it has a PROXY entry andthe AP is not the root AP, then an ALERT request is sent to the root AP.If the path to the node has changed, the root AP will return an ALERTresponse to delete the old path fragment.

(9) LOCAL entries are aged and discarded after 30 minutes. PENDINGentries are aged and discarded after 2 minutes. PROXY entries aredeleted if the route to the associated node changes.

FIG. 6 is a drawing of an exemplary enterprise network used toillustrate the functionality of address resolution using ARP proxyservers in accordance with the present invention. A terminal 615 has anIP address for a subnet 612. Assume that the terminal 615 has eithersent an inbound ARP frame or registered its IP address within an ATTACHrequest packet. The ARP server in an AP 603 has a PROXY entry for theterminal (assuming the AP 603 has bridging enabled). A server in an AP602 has a LOCAL entry for the terminal 615 because the route for theterminal 615 is distributed, i.e., the AP 603 is responsible forbridging frames from ethernet to the terminal 615. A root AP 601 cannothave an entry for the terminal 615 because it is on another subnet 611.If an IP Host 642 sends a broadcast ARP request frame with the target IPaddress of the terminal 615, then the server in the AP 603 will generatean ARP response frame which contains the ethernet address of theterminal 615. The AP 602 will ignore the request. The path between theAP 602 and the AP 603 could contain an off-the-shelf transparent bridge.If the request is flooded inbound, any AP on the subnet 611 will alsoignore the request because the target IP address is on another subnet.An IP Host 641 will initiate a conversation with the terminal 615 bysending an ARP request with a target IP address that designates port 631on the IP router 623.

The proxy ARP server can be configured so that ARP requests are neverforwarded outbound from an ethernet segment into the radio network. Inthis case, the server needs to have perfect knowledge of any IP nodescontained within the sub tree rooted at the AP, so that it can generateproxy ARP responses. Normally, this mode is used if all nodes in theradio network explicitly register their IP addresses.

By default, a broadcast ARP request packet, or any other broadcastpacket, which originates in the radio network is forwarded inbound untilit reaches the primary LAN. The multicast flooding level can be set sothat broadcast frames are always flooded throughout the OWL network.

Two or more APs may generate ARP response packets for a single node, ifan old path is not successfully deleted when the node roams. In thiscase, the forwarding database in an off-the-shelf bridge may be updatedincorrectly. An equivalent problem in an OWL AP has been corrected bynot submitting ARP response frames to the backward learning process.Previously, the backward learning logic in the AP assumed that a framecould not be delayed for more than 5 seconds. If an AP received a frameon the primary LAN, for example, and it had an outbound route for thesource address, then it deleted the route, if the route was more than 5seconds old. This logic fails if an AP continues to generate ARPresponse frames for a terminal, for some time after the terminal hasroamed to another AP. To avoid incorrect updates, the filtering databaseand route tables in an OWL AP are not updated when a received ARPresponse indicates that the path to the source node may have changed.Instead, an ALERT request is generated to determine if the node has, infact, roamed. If an ALERT response indicates that the node has roamed,then the AP will delete its PROXY server entry for the node and will nolonger generate incorrect ARP responses for the node.

FIG. 7 is a drawing of an exemplary enterprise network used toillustrate the functionality of address resolution using ARP translationservers in accordance with the present invention. In particular, anotherapproach involving the use of ARP translation servers often proves to bea more desirable solution to that provided by the proxy ARP serverapproach of FIG. 6. The ARP translation prevents undesirable flooding ofARP requests through radio and tunnel links.

An ARP translation server operates nearly identically to the proxy ARPserver discussed with reference to FIG. 6. Instead of acting as a proxy,the ARP translation server unicasts ARP requests through the wirelessnetwork. Thus, whether or not an ARP request is received on an inboundor an outbound link, the ARP translation server will translate thebroadcast destination address, in the ethernet header, to the unicastethernet address of the target node, if the ARP translation server hasPROXY entry for the target IP address. The unicast frame is then routedthrough the OWL network to the target node so that the target node canreturn an ARP response packet.

In the exemplary enterprise network of FIG. 7, a terminal 715 has an IPaddress for a subnet 712. Assume that the terminal 715 has either sentan inbound ARP frame or registered its IP address within an ATTACHrequest packet. The ARP server in an AP 703 has a PROXY entry for theterminal (assuming the AP 703 has bridging enabled). A server in an AP702 has a LOCAL entry for the terminal 715 because the route for theterminal 715 is distributed, i.e., the AP 703 is responsible forbridging frames from ethernet to the terminal 715. A root AP 701 cannothave an entry for the terminal 715 because it is on another subnet 711.If an IP Host 742 sends a broadcast ARP request frame with the target IPaddress of the terminal 715, then the server in the AP 703 willtranslate the broadcast destination address, in the ethernet header, tothe unicast ethernet address of the target node, the IP terminal 715.The unicast frame is then transmitted to the IP terminal 715. The IPterminal 715 responds with an ARP response packet which is a unicastpacket directed to the IP host 742 via the AP 703.

Thus, unlike the proxy ARP server approach, the ARP translation serverapproach does not require the server to have perfect knowledge of the IPnodes contained within the sub-tree at the corresponding AP. Instead,the ARP translation server merely directing (unicasting) the ARP requestwhen it believes an IP node is contained within its subtree. Whether ornot this is true does not matter because the IP node will only respondwith an ARP response if it is present and has not roamed.

Although FIGS. 1-2 and 4-7 are diagrams with simplistic networkconfigurations with a single wireless hop to a terminal, theaforementioned features and functionality can also be applied to morecomplex configurations including enterprise networks with multiplewireless hopping pathways to such terminals.

FIG. 8 a is a drawing illustrating operation of an augmenting whichsupplements off-the-shelf protocol stacks to support various enhancedfeatures. A typical off-the-shelf protocol stack would include aproprietary or defacto industry standard driver 801, which provides aMAC layer interface to higher level protocol layers such as TCP/IP 803or IPX/SPX 805. Exemplary MAC layer interfaces are defined by industrystandards such as ODI (open data link interface) or NDIS (network deviceinterface specification) among others.

Using a conventional approach to enhance functionality, higher levellayers of the protocol stack such as the TCP/IP 803 or the IPX/SPX 805would be modified creating potential incompatibility and duplicity inefforts. Instead, an augmenting agent 807 has been added to interfacewith the off-the-shelf protocol stacks to provide the enhanced featuresof an enterprise network built in accordance with the present invention,without requiring modification to the off-the-shelf protocol stacks. Theaugmenting agent 807 is placed as an independent application to monitorthe interface between the driver 801 and the higher layer protocols,e.g. TCP/IP 803 and the IPX/SPX 805.

FIG. 8 b is a drawing illustrating an alternate implementation of theaugmenting agent of FIG. 8 a wherein, instead of operation as anindependent, monitoring application, the augmenting agent operates as ashim between the driver and the higher level protocols. Specifically, aproprietary or defacto industry standard driver 851 interfaces withprotocols TCP/IP 853 and IPX/SPX 855 via the augmenting agent 857.Although the augmenting agent may intercept all intended exchangesbetween the driver 851 and the protocols 853 and 855, the augmentingagent 857 need only intercept those exchanges necessary to provide thedesired enhanced functionality. The driver 851 is unaware of theexistence of the augmenting agent 857 as are the protocol layers 853 and855. Such is the case in FIG. 8 a as well.

The functionality described above regarding ARP registration is carriedout by an augmenting agent. Other functionality that might be addedthrough the augmenting agent includes, for example: (1)encypherment/encryption; (2) device authentication; (3) global networkconfiguration; (4) diagnostics such as loop-back testing, signalstrength feedback, wireless retry counts, network route tracing, networkmanagement via SNMP agent functionality; and (5) filtering and floodingrestrictions. Thus, using the augmenting agent, these and other enhancedfunctions can be added transparent to a given proprietary protocolstack.

FIG. 9 is a block diagram of a communication system illustrating the useof an IP tunnel and a data link tunnel to access a roaming terminal inaccordance with the invention. A network 900 comprises two subnets 902and 904. A router 906 connects the subnets 902 and 904. A mobile IPterminal 908 a originally contacts the network 900 through a root accesspoint (AP1) 910 of a wireless network, such as an OWL network. As shown,the root access point 910 is a part of the subnet 902. The mobile IPterminal has a wired network address respective to the root access point910.

The mobile IP terminal 908 a subsequently roams, shown as the mobile IPterminal 908 b. has moved. The mobile IP terminal 908 b now contacts thenetwork 900 through another access point 912 of the OWL network. Theaccess point 912 is part of the subnet 904.

An IP host 914 communicates with the IP terminal 908 through the rootaccess point 910 by the methods described previously in thisspecification. To access the mobile IP terminal 908, the IP host 914directs data to the root access point 910 through the router 906. An IPtunnel 916 is created between the root access point 910 and anotheraccess point 918 for the subnet 904. The access point 918 serves as aroot access point for other wireless access points in the subnet 904.

The access points 918 and 912 are nodes in an OWL network. Thus, theroot access point 910 may transmit OWL packets through the IP tunnel 916to the mobile IP terminal 908.

In order to facilitate faster access to the mobile IP terminal 908through the access point 912, a data link tunnel 920 is created betweenaccess point 912 and the access point 918. This data link tunnel enablesdata to flow from the access point 918 to the access point 912, where itis forwarded to the mobile IP terminal 908. The data link tunnel allowsthe data to be passed between the access point 918 and the access point912 without the necessity of bridging the data onto the subnet 904.Thus, the IP host 914 can communicate with the mobile IP terminal 908without having to bridge the data onto the subnet 904 after the datareaches the access point 918.

To communicate with the mobile IP terminal 908, the IP host 914 sends apacket addressed to the mobile IP terminal 908. The IP host 914 forwardsthe packet to the router 906, where the router 906 forwards the packetfrom the IP host 914 to the subnet 902.

There, the root access point 910 forwards the data packet to the accesspoint 918 via the IP tunnel 916. The access point 918 then forwards thepacket to access point 912 via the data link tunnel 920. The data linktunnel enables the access point 918 to pass data to the access pointwithout bridging the data packet onto the subnet 904. Thereafter, theaccess point 912 directs the data packet to the mobile IP terminal 908.

More specifically, the mobile IP terminal 908 is connected to an OWLnetwork, in this case consisting of the root access point 910 and theaccess point 918 that serves as a root for the subnet 904. The subnet904 connects the third access point 912 to the access point 912 in theOWL network. The connection between the access point 918 and the accesspoint 912 may be via a wired or wireless connection.

The mobile IP terminal 908 b has a wired network address relative to theroot access point 910. The mobile IP terminal 908 b wanders fromposition 908 a and connects to the the network 900 via the access point912. Assume that the IP host 914 sends a packet of data directed to themobile IP terminal 908 b. Initially, the IP host 914 sends an IP packetto the root access point 910 via the router 906 using the IP address ofthe IP terminal 908 b. Upon receipt, the root access point 910encapsulates the IP packet in an OWL packet. The root access point 910encapsulates the resulting OWL packet within another IP packet addressedto the access point 918. The IP packet is then sent to the access point918 via the IP tunnel 916.

The access point 918 de-encapsulates the original IP data andre-encapsulates the IP data in an OWL data frame. The access point 918then forwards the re-encapsulated packet to the access point 912 throughdata link tunnel 920. The access point 912 de-encapsulates the originalIP data and forwards it to the mobile IP terminal 908.

The data link tunnel 920 is established by disabling bridging on theaccess point 918. When bridging is disabled, no data is bridged onto thesubnet 904.

FIG. 10 is a drawing illustrating an exemplary protocol stack associatedwith the access point at the endpoints of the IP tunnel and the datalink tunnel illustrated in FIG. 9. When a bridging protocol 1010 isdisabled, any incoming packets of data cannot flow through the bridginglayer 1010 to a TCP layer 1012 or to an ethernet MAC layer 1014.

When the bridging protocol 1010 is disabled, the data packets must flowthrough the MAC-R protocol layer 1020. The packets then flow to thevarious MAC-D protocols, such as a MAC-D ethernet layer 1030, a MAC-Dradio layer 1040, and an IP MAC-D protocol layer 1050.

A line 1070 in FIG. 10 illustrate the paths an IP data packet destinedto the mobile IP terminal 908 can take through the protocol stack 1000in access point 918 when the data link tunnel 920 is activated. Line1070 illustrates the path the IP data packet takes when access point 918connects to access point 912 via an ethernet link. In this case, thepacket enters the protocol stack 1000 through the IP MAC-D protocollayer 1050. This corresponds to the data packet entering the accesspoint 918 via the IP tunnel 916. The MAC-R protocol layer 1020 thenprocesses the data packet. Since bridging on the access point 918 hasbeen disabled, the data packet need not enter the bridging protocollayer 1010. The MAC-R protocol layer 1020 turns the processing of thedata over to the MAC-D ethernet protocol layer 1030 for processing. TheMAC-D ethernet protocol layer 1030 then formats the data packet fortransmission to the access point 912 via an ethernet physical protocollayer 1060.

FIG. 11 is a drawing illustrating an exemplary protocol stack associatedwith the access point at the endpoints of the IP tunnel and the datalink tunnel illustrated in FIG. 9. A line 1080 illustrates the path ofthe packet through the protocol stack 1000 when access point 912connects to access point 918 via a radio link. As before, the IP datapacket enters the protocol stack through the IP MAC-D protocol layer.The data packet is then processed by the MAC-R protocol layer 1020. Thedata packet is then turned over to the MAC-D radio protocol layer fortransmission to access point 912.

Note that in both cases, the encapsulated IP packet did not cause accesspoint 918 to bridge the data onto the subnet 904 during the transfer ofthe IP packet to the access point 912.

Thus, the access points 912 and 918 serve as logical extensions of thesubnet 902. A home subnet, such as the subnet 902, can be transparentlyextended into an enterprise IP network, such as network 900, byconcatenating data link tunnels, such as the data link tunnel 920, to anexisting IP tunnel, such as IP tunnel 916. The data link tunnels preventframes passing through an IP tunnel from one IP subnet to another frombeing bridged onto the second subnet.

In view of the above detailed description of the present invention andassociated drawings, other modifications and variations will now becomeapparent to those skilled in the art. It should also be apparent thatsuch other modifications and variations may be effected withoutdeparting from the spirit and scope of the present invention as setforth in the claims which follow.

Incorporation by Reference

Pages 35-308 comprises the following Appendices which are herebyincorporated herein by reference in their entirety: APPENDIX A OWLNETWORK ARCHITECTURE Pages 35-61 APPENDIX B OPEN WIRELSS LAN THEORYPages 62-250 OF OPERATION APPENDIX C OWL NETWORK FRAME FORMATS Pages251-264 APPENDIX D UHF/DIRECT SEQUENCE MAC-D Pages 265-308 PROTOCOLSPECIFICATION

1. A communication network providing wireless communication within apremises, the wireless network comprising: a wired network operatingaccording to a wired protocol, the wired network having a first networksegment and a second network segment; a wireless terminal having a wirednetwork protocol address; a first access point coupled to the firstnetwork segment; a second access point coupled to the first networksegment; and a data link tunnel that communicatively couples the secondaccess point to the first access point when the wireless terminal is inwireless communication with the second access point.
 2. Thecommunication network of claim 1 wherein the first access point isconnected to the first network segment.
 3. The communication network ofclaim 2 wherein a protocol tunnel communicatively couples the firstaccess point to the second network segment.
 4. The communication networkof claim 3 further comprising a third access point connected to thesecond network segment.
 5. The communication network of claim 4 whereinthe wireless terminal has a wired network protocol address respective tothe third access point.
 6. The communication network of claim 5 whereinthe first access point and the third access point are communicativelycoupled with a protocol tunnel.
 7. The communication network of claim 6wherein routed communication through the data link tunnel uses adifferent protocol scheme than when routed through the protocol tunnel.8. The communication network of claim 1 wherein the wired networkoperates under the Internet protocol.
 9. The communication network ofclaim 1 wherein the data link tunnel operates across the wired network.10. The communication network of claim 1 wherein the data link tunneloperates across a radio link.
 11. The communication network of claim 1wherein routed communication from the first tunnel is not bridged ontothe second network segment.
 12. A communication network comprising: awired network having a first network subnet and a second network subnet;a first tunnel coupling the first network subnet with the second networksubnet; a roaming terminal communicatively coupled with the firs networksubnet; and a second tunnel concatentated with the first tunnel toprovide a logical extension of the first subnet for the roamingterminal.
 13. The communication network of claim 12, wherein thecommunication network further sends a data message destined to theroaming terminal as a first message under a first network protocol, thefirst message encapsulating a second message under a second networkprotocol, the second message encapsulating a message under the wirednetwork protocol.
 14. The communication network of claim 13 wherein thesecond network protocol is a wireless network protocol.
 15. Thecommunication network of claim 13 wherein the second network protocol isa wired network protocol.
 16. The communication network of claim 12wherein the wired network operates under an Internet protocol.
 17. Thecommunication network of claim 12 wherein the second tunnel operatesacross the wired network.
 18. The communication network of claim 12wherein the second tunnel operates across a radio link.
 19. Thecommunication network of claim 12 wherein a routed communication fromthe first tunnel is not bridged onto the second network subnet.
 20. Acommunication network comprising: a wired network having a first networksubnet and a second network subnet; a first tunnel coupling the firstnetwork subnet with the second network subnet; a roaming terminalcommunicatively coupled with the first network subnet; and a secondtunnel concatentated with the first tunnel to provide a logicalextension of the first subnet for the roaming terminal without requiringthe dynamic assignment of pseudo addresses.
 21. The communicationnetwork of claim 20, wherein the communication network further sends adata message destined to the roaming terminal as a first message under afirst network protocol, the first message encapsulating a second messageunder a second network protocol, the second message encapsulating amessage under the wired network protocol.
 22. The communication networkof claim 21 wherein the second network protocol is a wireless networkprotocol.
 23. The communication network of claim 21 wherein the secondnetwork protocol is a wired network protocol.
 24. The communicationnetwork of claim 20 wherein the wired network operates under an Internetprotocol.
 25. The communication network of claim 20 wherein the secondtunnel operates across the wired network.
 26. The communication networkof claim 20 wherein the second tunnel operates across a radio link. 27.The communication network of claim 20 wherein a routed communicationfrom the first tunnel is not bridged onto the second network subnet. 28.A communication network providing wireless communication within apremises, the wireless network comprising: a wired network operatingaccording to a wired protocol, the wired network having at least a firstnetwork segment and a second network segment; a wireless terminal havinga wired network protocol address; a first fixed access point connectedto the second network segment; a second fixed access point connected tothe second network segment; and a data link tunnel that communicativelycouples the first and the second fixed access points via wirelesscommunications only such that bridging communication data onto thesecond network segment is avoided when communications between one of thefixed access points and the wireless terminal require communication withthe other fixed access point.
 29. The communication network of claim 28wherein the data link tunnel comprises a radio link between the firstand the second fixed access points.
 30. The communication network ofclaim 28 wherein the wireless terminal is a roaming terminal.
 31. Thecommunication network of claim 30 wherein the first fixed access pointencapsulates a message in a packet for transmission via the data linktunnel to the second fixed access point such that the message issupplied to the wireless terminal without the use of pseudo addresseswhich are dynamically assigned to roaming terminals.
 32. Thecommunication network of claim 28 further comprising a router thatcouples the first and the second network segments.
 33. The communicationnetwork of claim 28 wherein the first network segment and the secondnetwork segment have different sub-network addresses.
 34. Thecommunication network of claim 28 wherein the wired network operatesaccording to an internet protocol.
 35. A communication networkcomprising: a wired network having a first network access point and asecond network access point; a data link tunnel communicatively couplingthe first network access point with the second network access point viawireless communications only; and a roaming terminal communicativelycoupled to the first network access point wherein communications fromthe roaming terminal pass within the data link tunnel to the secondnetwork access point.
 36. The communication network of claim 35 whereinthe data link tunnel comprises a radio link between the first and thesecond network access points.
 37. The communication network of claim 35wherein the roaming terminal is a wireless terminal.
 38. Thecommunication network of claim 37 wherein the first network access pointencapsulates a message in a packet for transmission via the data linktunnel to the second network access point such that the message issupplied to the wireless terminal without the use of pseudo addresseswhich are dynamically assigned to roaming terminals.
 39. Thecommunication network of claim 35 wherein the wired network operatesaccording to an internet protocol.